<html>

<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<title>-addftr template</title>
</head>

<body bgcolor="#FFFFCC">

<pre>-addndt
template: pers?clnt=&lt;name|pass&gt;&amp;com=addndt&amp;sid=&lt;id&gt;&amp;usr=&lt;usr&gt;[&amp;tms=&lt;timestamp_pattern&gt;]&amp;&lt;ftr_1&gt;=&lt;value_1&gt;&amp;&lt;ftr_2&gt;=...
          Order of query params are not important: the timestamp applies
          to all features in request. Feature values must be numeric.
pattern : - | &lt;date/time&gt;, where '-' means that the PServer assigns a
          transaction timestamp, otherwise the &lt;date/time&gt; provided by
          the application is used. The &lt;date/time&gt; format must be a
          long integer giving the milliseconds passed since January
          1st, 1970 00:00:00.000 GMT. The pattern is optional. In
          case it is missing, its value is assumed '-' (PServer assigns
          a transaction timestamp).
descript: for the specified user and for each 'ftr' parameter in the
          request, a new tuple (user, feature, value, timestamp, sid ) is
          inserted in table 'num_data'. In case the timestamp is
          provided by the application, it denotes when all the (user,
          feature) interactions took place. In case the timestamping is
          is delegated to PServer, it is the date/time of the
          insertion of the tuples in the DB (the transaction time).
          In both cases the timestamps can be used to put feature
          interactions in the order they occured. For this however,
          timestamping of all features must be consistent and correct
          (either PServer or application generated, not both / mixed).
          If a request contains many features they will have identical
          timestamps. This does not create any problem as long as the
          features are different. If the sid is ommited then the last sid 
          is assumed to be the desirable. The DB however cannot record more
          than one identical (user, feature, timestamp, sid ) tuples. For
          timestamps that are the same, the order of the corresponding
          interactions will be arbitrary. If a timestamp pattern is
          not legal, or if the request leads to two or more identical
          tuples, or the value of some feature is not numeric, 401 is
          returned. If the error code 401 is returned then no changes
          have taken place in the DB.
example : pers?clnt=name|pass&amp;com=addndt&amp;usr=kostas&amp;tms=1005854668670&amp;laptop.weight=2.55
returns : 200 OK, 401 (fail, request error), 501 (fail, server error)
200 OK  : in this case the response body is as follows
          &lt;?xml version=&quot;1.0&quot;?&gt;
          &lt;?xml-stylesheet type=&quot;text/xsl&quot; href=&quot;/resp_xsl/rows.xsl&quot;?&gt;
          &lt;result&gt;
          &lt;row&gt;&lt;num_of_rows&gt;number of relevant rows&lt;/num_of_rows&gt;&lt;/row&gt;
          &lt;/result&gt;
comments: the reference to the xsl file allows to view results
          in a web browser. In case the response body is handled
          directly by an application and not by a browser, this
          reference to xsl can be ignored.</pre>

</body>

</html>
